During the past years, the evolution of various portable devices, e.g., mobile phones, personal digital assistants, etc. was driven by the idea of adding “smart” features. The smart features include, among other things, the capability to browse the Internet while on the move. For directing the end user requests to the best server for fetching the desired content, the Internet based content delivery network (CDN) companies, e.g., Akamai, use DNS redirection. The best location of the server may be expressed based on various parameters, e.g., closest topological proximity, shortest time to live (RTT), least load of the server, etc.
While the DNS redirection works well in the public Internet, there are some challenges in ensuring DNS redirection operation in mobile telecommunication networks, e.g., third generation (3G) or Long Term Evolution (LTE) networks. These mobile telecommunication networks are built in such a way that an identity of a mobile phone (e.g., Internet protocol (IP) address) may not be visible from outside the network. Thus, a CDN company cannot provide the best server for the mobile phone as the CDN company cannot “see” the internal structure of the mobile network. As the mobile telecommunication networks have their own content servers (caches) which may be used in response to the requests of the mobile phones and because the CDN companies do not see these servers, little use is currently made of these content servers by CDN companies.
A brief discussion about the DNS is believed to be in order here for a better understanding of the exemplary embodiments. Domain name service is a know Internet service which is used to resolve fully qualified domain names (FQDNs) to IP addresses (this is defined in RFC 1034 and RFC 1035, see http://www.ietf.org, the entire contents of which are incorporated herein by reference). A format of a traditional DNS query message 10 is shown in FIG. 1 and it includes a header field 12, a question field 14, an answer field 16, an authority field 18, and an additional field 20. The question field 14 of the header 10 includes a QNAME field 22 as shown in FIG. 2. The QNAME field may carry the name of the resource which is to be resolved.
DNS redirection is used in the Internet to facilitate selection of cache servers based on DNS resolution mechanisms. Various CDN companies use these techniques extensively. For example, such companies (e.g., Akamai) require their customers to modify their web pages to explicitly write in their universal resource locator (URL) a domain name pointing to Akamai servers. A special tool may be used for this conversion. For example, Akamai have used to “akamize” the URLs of its customers with such a tool. However, this particular company uses today a technique (CNAMing) whereby the customers delegate ownership of their domain name to Akamai.
For example, CNAMing involves configuring the DNS of client xyz so that a request for www.xyz.com corresponds to CNAME www.xyz.com.edgesuite.net. for the given client. The content originator (e.g., xyz.com) references objects in its web pages using standard convention, for example, <img alt=“Building on the past” src=“/res/the company/images/2009/091110_history—180×90.jpg”/>. The content of xyz is either pulled or pushed into the Akamai caches so that both xyz and Akamai have control over load distribution. In the following, the term “content originator” refers to those companies or web sites that create (originate) the content and the term “content delivery provider” refers to those services that distribute (provide) the existing content to the users (e.g., Akamai).
The CNAMing DNS resolution flow is illustrated in FIG. 3. FIG. 3 shows that a user device 30 uses a browser to request a web page with an embedded image from xyz. The user device 30 sends to a local DNS 32, in step A1, a DNS query for a desired content (e.g., xyz.com). The local DNS 32 transmits the query in step A2 to a DNS 36 of the xyz web server 38. It is noted that the local DNS 32 is part of the communication network to which the user device 30 belongs to. The local DNS is sometimes called ISP DNS and it is provided inside the operator's network (fixed or mobile) and it is responsible for name resolution of domain names of the operator. The IP address of the local DNS server is provisioned in all the user devices that connect to the operator's network (e.g., via dynamic host configuration protocol (DHCP)), i.e., the user devices are aware of its existence. On the contrary, a root DNS 34 is a general server, e.g., this is a public DNS server of the Internet and it is located in the public Internet.
In step A3, the xyz DNS 36 returns an URL associated with the CDN delivery provider 40 to the local DNS 32. The local DNS 32 sends in step A4 a DNS query to the CDN delivery provider 40 based on the received URL. After exchanging a few messages in steps A5 to A8 with the CDN delivery provider 40 (which may include one or more servers), the local DNS 32 receives in step A9 an IP address of a content server of the CDN delivery provider 40. The local DNS 32 sends in step A10 the received IP of the content server of the CDN delivery provider 40 having the desired content to the user device 30. Finally, in step A11, the user device 30 sends a request for the desired content to the CDN delivery provider 40 and receives in step A12 that content from the server 40.
As mentioned above, another method currently used by some CDN delivery providers (e.g., Akamai) is to modify the URLs of the content originator (e.g., xyz). Using again the example of Akamai and xyz (please note that other content delivery providers and content originators may be used), the URLs of xyz may be Akamaized in the following manner. The domain xyz.com may use a special tool to Akamaize all links in its web pages, i.e., the Akamai domain name is placed in all URLs. For example, a conventional URL pointing to a picture on the xyz web site is <img src=http://xyz.com/Ads/adinfo_top.gif . . . > and becomes <img src=http://a1010.g.akamai.net/cnwk.1d/Ads/adinfo_top.gif . . . > after being akamaized. The new URL includes now a reference to akamai.net.
The akamaized URL DNS resolution flow is illustrated in FIG. 4. FIG. 4 is similar to FIG. 3 and for this reason the similar steps of these two figures are not repeated here.
A common feature of the existing DNS based redirection systems is the reliance on the local DNS server identity as well as the IP address of the requesting client to select the closest cache that has the desired content and/or to improve the quality of experience (QoE). However, if the caches storing the desired content are deployed inside the telecommunication network, for example, below the Gateway GPRS support node GGSN (GGSN) in a 3GPP network (e.g., at the radio network control (RNC) level), the current mechanisms for cache selection will fail. One of the reasons for this is that the GGSN is the IP anchor point for all IP entities below itself.
Accordingly, it would be desirable to provide devices, systems and methods that avoid the afore-described problems and drawbacks.